@uppy/aws-s3: fix server generated keys not getting returned - #6498

fixes #6496

NO AI USED in code

we were always passing client generated keys from s3Opts methods ,

see :

in #onSuccess we're passing key returned from putObject

putObject directly returns the key it gets in params which is the client generated key

people can modify these keys on their signing backends, when a signing backend stores the object under a different key:

• Single-part: upload succeeds, but upload-success reports a key that doesn't exist in the bucket. This is the reported issue in In @uppy/aws-s3 6.0, the key returned in file.response.body.key is the client-generated key, not the server-generated one #6496

• Multipart: the reported key was correct (it's parsed from S3's CompleteMultipartUpload response), but the client key was used internally for every part/complete/abort request and persisted as s3Multipart.key for Golden Retriever. That only works if the server maps client→server key deterministically on every call; a server that generates a unique key fails at the first uploadPart with NoSuchUpload.

Fix

• signRequest may now return { url, key }. request() resolves the key once (signedKey || request.key), and putObject / createMultipartUpload return it.
• key is optional: signers that return only { url } get exactly the previous behaviour, so this is non-breaking. Servers that sign for a key other than the one requested must return it the plugin has no way to detect the change otherwise.